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REMARKS 

Applicants express appreciation to the Examiner for the recent interview held with 
applicants' representative. As presented herein for reconsideration, the claims have been 
amended as proposed at the interview. Specifically, dependent claims 4, 8, 13 and 16 have been 
amended, claims 1 - 3, 5 - 7, 9 - 12, 17 - 34 have been cancelled without prejudice. New 
claims 35 - 40 have been presented. Thus, by this paper, claims 4, 8, 13, 16, and 35 - 40 are 
pending, of which claims 35 and 36 are the independent claims. 

In the Office Action all of the claims were rejected 1 either under 35 U.S.C. § 102(e) as 
anticipated by U.S. Pat. Pub. No. 2003/0172118 (Bilansky), 2 or under 35 U.S.C. § 102(a) as 
obvious over Bilansky and further in view of either RFC 1739, U.S. Pat. No. 7,209,911 
(Boothby) or U.S. Pat. No. 6,647,409 (Sherman). 

As presented herein for consideration, applicants' invention is directed to a method and a 
corresponding computer program product for implementing the method, which are adapted for 
use in a computing network comprised of a plurality of interconnected servers for transferring 
messages among the interconnected servers. At least some of the servers use a communication 
protocol that is not configured for communicating filtering information to the server, and the 
computing network also comprises a plurality of client side computing devices for accessing the 
servers and downloading messages. As claimed, the method uses client-side tracking 
mechanisms to allow a client side computing device to efficiently determine which messages 
need to be downloaded for filtering at the client side computing device, so that essentially most 
of the filtering operations occur before the messages are downloaded. Specifically, the method 
comprises setting at a client side computing device a filter criteria for new messages, then 
receiving at the client side computing device a list that identifies the messages maintained at a 
server using a communication protocol that is not configured for communicating filtering 
information to the server. The client side computing device then retrieves a message store table 
that contains records identifying messages that have met the filter criteria, and marks each record 

' Claims 33 and 34 were objected to as not containing complete text as presented in the preliminary amendment. 
Those claims have been canceled by this amendment. 

2 Since Bilansky and Boothby qualify as "prior" art, if at all, under 35 U.S.C. 1 02(e) applicants reserve the right to 
challenge the status of either reference as qualifying "prior" art. Accordingly, any statement or comment herein 
concerning either reference is made merely for purposes of argument, and assumes arguendo that the reference is 
proper qualifying prior art. 
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with a flag. Next, the client side computing device retrieves a checked table that contains 
records identifying messages that have not met the filter criteria, and marks each record with a 
flag. The messages in the received list are then compared with the records contained in the 
message store table and the checked table, so that only those messages that do not already 
correspond to a record in either the message store table or the checked table are downloaded to 
an inbox at the client side computing device. This limits the download time only to new 
messages. The client side computing device then unmarks the flags for all records contained in 
either the message store table or the checked table that already correspond to messages identified 
in the list, and checks the new messages downloaded against the filter criteria, and either adds a 
new unmarked record to the message store table if the filter criteria is met, or else adds a new 
unmarked record to the checked table if the filter criteria is not met. Lastly, any remaining 
records with marked flags in the message store table and the checked table are removed from the 
tables. 

Bilansky discloses a method of providing POP3 support for limited storage devices, 
which seeks to provide some of the "advantages associated with IMAP server systems." [0043] 
As disclosed, note that Bilansky, unlike applicants' described (see Figs. 2-3) and claimed (see 
independent claims 35 and 36) method, "elects to keep mail on the server ... 702 [Fig. 7] by 
configuring POP3 mail server 700 to "not" delete the electronic mail message upon receipt and 
by "not" copying the messages to the local storage on client device 704 from inbox 706 on server 
. . . 702." [0045] Further, Bilansky discloses that "No local inbox is present on client device 
704, which is similar to IMAP. Instead, mail list 708 in client device 704 is an interface 
illustrating header information for mail list messages displayed in mail list 708. . . . This 
arrangement results in all incoming mail messages residing on the server as opposed to the 
client." [0045 - 0046] Bilansky specifically notes that "Individual electronic mail messages are 
retrieved when and if the user selects an electronic mail message from mail list 708 for display." 
[0047] (Emphasis added). 

In contrast, applicants' claimed method (see independent claims 35, 36 and 28) does not 
require the user to specifically select a message for display, but rather downloads all new 
messages after it has been determined that the message (1) does not correspond to a record 
already contained in either the message store table or the checked table, and (2) meets the filter 
criteria set by the user at the client side device. There is no teaching or suggestion in Bilansky as 
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to screening new messages in this way. Bilansky does not disclose or suggest either the message 
store table (against which the server's message list is checked for records indicating a message in 
the list is already in the message store table and hence meets the user's filter criteria), or the 
checked table (against which the server's message list is checked for records indicating a 
message has already been marked as not meeting the user's filter criteria), or downloading only 
the new messages which are then checked against the user's filter criteria so that either the 
records in the message store table or checked table are updated based on the outcome of that 
filter check. 

Sherman, which was also discussed in the interview, identifies items at the server that are 
not present the client device, and then downloads the header for each of those identified items. 
See, e.g., the Abstract. "The header information is analyzed to determine whether to download 
the entire item based on predetermined criteria, such as date information. Once all server-based 
items are analyzed, and selected items are downloaded, all local copies of items, that do not 

satisfy the predetermined criteria, are deleted " Id. 

Note, however, that there is nothing in Sherman which discussed comparing the list of 
items at the server with both a list of items maintained at the client device which meet the filter 
criteria set by the client, and which also compares the server list with records indicating an item 
has already been marked as not meeting the user's filter criteria. Thus, even if Sherman were 
properly combinable with Bilansky 3 the asserted combination still would not meet the claim 
limitations as set forth in claims 35 and 36, which require, inter alia, 

"comparing the messages identified in the received list with the records 
contained in the message store table and the checked table and then downloading 
to an inbox at the client side computing device only those messages that do not 
already correspond to a record in either the message store table or the checked 
table, so that download time is limited only to new messages, and unmarking the 
flags for all records contained in either the message store table or the checked 
table that already correspond to messages identified in the list; 



3 As noted at the Interview, Sherman is not properly combinable with Bilansky in any event. That is because 
Bilansky is, in at least one important aspect, contrary to Sherman. Bilansky expressly states that "No local inbox is 
present on client device 704, which is similar to IMAP. Instead, mail list 708 in client device 704 is an interface 

illustrating header information for mail list messages displayed in mail list 708 This arrangement results in all 

incoming mail messages residing on the server as opposed to the client." [0045 - 0046] As noted above, Sherman, 
on the other hand, discloses that "Those items located on the server and not on the H/PC [e.g., client device] me 
selected for possible downloading to the H/PC." Abstract. Thus, Sherman teaches that the client device does 
maintain messages on the client device and then analyzes header information for those messages at the server which 
are not already on the client device. Id. 
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checking the new messages downloaded against the filter criteria, and 
either adding a new unmarked record to the message store table if the filter 
criteria is met, or else adding a new unmarked record to the checked table if the 
filter criteria is not met; and 

removing any remaining records with marked flags in the message store 
table and the checked table." (Claims 35 and 36, emphasis added). 

Boothby is even more removed from Bilansky than Sherman. Boothby is directed to a 
method for synchronizing a first and a second database. The two databases may contain records 
which provide essentially the same information, but differently formatted. "For example, one 
database may store names and addresses in the following fields: FIRST_NAME, LASTNAME, 
AND ADDRESS. Another database may, however, store the same information with the 
following structure: NAME, STREET_NO., STREET_NAME, CITY STATE, AND ZIP." 
Col. 1 lines 53 - 58. Thus, Boothby teaches that "At least one of the identified records o f the 
first database is then synchronized with a record of the second database" but only for those 
"records of the first database fitting a selected criterion [e.g., those which contain the same 
information as certain records in the second database, for example, FIRST_NAME, 
LAST_NAME with NAME, in the example noted above]." Abstract. (Bracketed statement 
added). 

Lastly, RFC 1739 was cited merely as teaching hashing, but otherwise provides nothing 
which would solve the deficiencies of Bilansky as already noted. Thus, as in the case of both 
Sherman and Boothby, even if combined with Bilansky, the combination fails to meet the 
claimed limitations set forth in claims 35 and 36 as noted. 

For at least the foregoing reasons, the claims as presented herein are neither anticipated 
nor made obvious by Bilansky, either singly or in combination with any other reference of 
record. As noted in the Interview Summary, "newly proposed claims 35 and 36 . . . seem to 
distinguish over the prior art of record." Accordingly, favorable reconsideration and allowance 
of the claims as presented herein is respectfully requested. 
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In the event the Examiner finds any remaining impediment to allowance of this 
application that may be clarified through a telephone interview, the Examiner is requested to 
contact the undersigned attorney. 



Dated this 9 th day of April, 2008. 



Respectfully submitted, 




RICK D. NYDEGGER 
Registration No. 28,651 
Attorney for Applicant 
Customer No. 047973 
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